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Documentation of IANA assignments for 
Constraint-—Based LSP setup using LDP (CR-LDP) Extensions 
for Automatic Switched Optical Network (ASON) 

Status of this Memo 

This memo provides information for the Internet community. It does 

not specify an Internet standard of any kind. Distribution of this 

memo is unlimited. 
Copyright Notice 

Copyright (C) The Internet Society (2003). All Rights Reserved. 
Abstract 


Automatic Switched Optical Network (ASON) is an architecture, 


specified by ITU-T Study Group 15, for the introduction of a control 


plane for optical networks. The ASON architecture specifies a set of 


reference points that defines the relationship between the ASON 
architectural entities. Signaling over interfaces defined in those 
reference points can make use of protocols that are defined by the 
IETF in the context of Generalized Multi-Protocol Label Switching 
(GMPLS) work. This document describes Constraint-—Based LSP setup 
using LDP (CR-LDP) extensions for signaling over the interfaces 


defined in the ASON reference points. The purpose of the document is 
to request that the IANA assigns code points necessary for the CR-LDP 


extensions. The protocol specifications for the use of the CR-LDP 
extensions are found in ITU-T documents. 
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1. Introduction 


Automatic Switched Optical Network (ASON) is an architecture, 
specified by ITU-T Study Group 15 (SG15), for the introduction of a 
control plane for optical networks. The development and the 
standardization of ASON has been done by ITU-T SG15 and is documented 
in recommendation G.8080 [1]. The architecture includes a control 
plane with a set of reference points between the architectural 
components. The ASON signaling that runs over interfaces defined in 
those reference points are described in ITU-T recommendation G.7713 
[2] 


Constraint-Based LSP Setup using LDP (CR-LDP) [3] is one of the 
protocols selected by the ITU for the realization of G.7713 and its 
dynamic connection management. The work specific to CR-LDP extensions 
for ASON is documented in ITU-T recommendation G.7713.3 [8]. 


This document introduces those CR-LDP extensions that are specific to 
ASON and requests IANA allocation of code points for these 
extensions. The document does not specify how these extensions are 
used; that is the subject of the above mentioned ITU-T documents. 
This document should be considered in conjunction with RFC 3036 [4], 
RFC 3212 [3], and CR-LDP extensions for GMPLS [5]. 


2. Overview of CR-LDP Extensions for ASON 


This document describes ASON specific CR-LDP extensions covering the 
following ASON signaling requirements: 


- Call and connection control separation 

— Support of Soft Permanent Connections (SPC) 
- Crankback 

- Additional error codes 


An important ASON architectural principle is the separation between 
the call and the connection controllers as described in G.8080. Call 
and connection control separation allows for a call with multiple 
connections associated with it. It also allows for a call with no 
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(a temporary situation that might be useful during 


The separation of the call and the connection controllers could be 


achieved using one of two models. 


call set up request 
The second model is 
from connection set 
logical separation, 


complete separation. 


separation models. 


Two new messages are introduced for call operations 


release). The Call 
complete separation 
message is used for 


A connection set up 
connection needs to 
achieve this goal. 


The first model is one where the 
is always accompanied by a connection request. 
one in which call set up is done independently 
up. The first model is usually referred to as 
while the second model is usually referred to as 
CR-LDP extensions for ASON support the two 


(set up and 
Setup message is used for those cases where 
is required. Otherwise the LDP Label Request 
logical separation. 


request must indicate the call to which the 
be associated. A Call ID TLV is introduced to 
The structure of the Call ID allows it to have a 


global or an operator scope. 


Call release is always achieved using the Call Release message. 


The 


reception of the call Release messages signifies the intention to 


remove all connections that are associated to the call. 


release is achieved 


LDP Label Release and Label Withdraw messages) 


Connection 
using the CR-LDP label release procedure (using 
as defined in [4]. 


A Call Capability TLV is also introduced to explicitly indicate the 
capability of the requested call. 


An Soft Permanent Connection 


(SPC) service assumes that both source 


and destination user-to-network connection segments are provisioned 
while the network connection segment is set up via the control plane. 
For example when the initial request is received from an external 


source, e.g. froma 
assumption that the 


determine the specific destination 
Support for CR-LDP is provided by the use of the Egress 


to use. 


Label TLV as defined in the OIF UNI 1.0 section 11.7.5 
Optical Internetworking Forum and in RFC3476 


CR-LDP Messages for 


management system, there is an implicit 

control plane has adequate information to 
(network-to-user) link connection 
[6] from the 
EYT 


ASON 


This section describes the formats and the procedures of the two 
messages that are required for ASON call and connection control 


separation. 
Release message. 
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Those messages are the Call Setup messages and the Call 
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3.1 Call Setup Message 
The format of the Call Setup message is: 
0 1 2 3 


O T2 345 678 9 0 1234 567-8 9 0 12 3°45 6 7-8 90I 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|O| Call Setup (0x0500) | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Message ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Source ID TLV | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Dest ID TLV | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Call ID TLV | 


EE EE a E E A ae? Nn E E T E ETA E. 
| Call Capability TLV | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+H+H+HHHH 
| Optional Parameters 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++H+HHH 


Message ID: 
Is as defined in RFC3036 [4]. 


Source ID TLV: 
Is as defined in UNI 1.0 [6] and in [7]. 


Dest ID TLV: 
Is as defined in UNI 1.0 [6] and in [7]. 


Call ID TLV: 
Is as defined in section 4.1 of this document. 


Call Capability TLV: 
Is as defined in section 4.2 of this document. 
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3.1.2 Call Setup Procedure 


The Calling party sends the Call Setup message whenever a new call 
needs to be set up with no connection associated with it. The Call 
Setup message shall contain all the information required by the 
network to process the call. In particular, the Call Setup message 
shall include the calling and called party addresses as specified by 
the Source ID and Dest ID TLV. The setup message must include Call 
ID TLV. The call control entity shall identify the call using the 
selected identifier for the lifetime of the call. The Call Setup 
message shall progress through the network to the called party. The 
called party may accept or reject the incoming call. An LDP 
Notification message with the appropriate status code shall be used 
to inform the calling party whether the setup is successful. The 
call can be rejected by either the network, e.g. for policy reasons, 
or by the called party. 


3.2 The Call Release Message 
This format of the Call Release message is: 
0 1 2 3 


0L -2 3A 8S Oe T g 970 TA 3 A a 7 8-9-0 2 3A T g 9 T0 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|o| Call Release (0x0501) | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Message ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Source ID TLV | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Dest ID TLV | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Call ID TLV | 


+-+-+-+-+-+-+-+- +++ 
| Optional Parameters | 
+-+-+-+-+-+-+-+- +++ 
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3.2.1 Call Release Procedure 


The Call Release message is sent by any entity of the network to 
terminate an already established call. The Call Release message must 
include the Call ID TLV of the call to be terminated. Confirmation 
of call release is indicated to the request initiator using a 
Notification message with the appropriate status code. Reception and 
processing of the Call Release message must trigger the release of 
all connections that are associated with that call. Connection 
release follows the normal CR-LDP procedure using Label Release and 
Label Withdraw messages. 


4. CR-LDP TLVs for ASON 


This section describes the operator specific Call ID TLV, the 
globally unique Call ID TLV, the Call Capability TLV and the 
Crankback TLV introduced for ASON. 


4.1 Call ID TLV 


An established call may be identified by a Call ID. The Call ID is a 
globally unique identifier that is set by the source network. The 
structure for the Call ID (to guarantee global uniqueness) is to 
concatenate a globally unique fixed identifier (composed of country 
code, carrier code, unique access point code) with an operator 
specific identifier (where the operator specific identifier is 
composed of ingress network element (NE) address and a local 
Identifier). 


Therefore, a generic CALL_ID with global uniqueness includes <global 
Id> (composed of <country code> plus <carrier code> plus <unique 
access point code>) and <operator specific Id> (composed of <NE 
address> plus <local Identifier>). For a CALL_ID that requires only 
operator specific uniqueness, only the <operator specific Id> is 
needed, while for a CALL_ID that is required to be globally unique 
both <global ID> and <operator specific Id> are needed. 


The <global Id> shall consist of a three-character International 
Segment (the <country code>) and a twelve-character National Segment 
(the <carrier code> plus <unique access point code>). These 
characters shall be coded according to ITU-T Recommendation T.50. 
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The format of the operator specific (Op-Sp) CALL_ID TLV: 
0 1 2 3 


01234567890123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|U|F|Op-Sp Call ID (0x0831) | Length 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| NE Address (NEA Sub TLV) | 


ee A AEE AE ey ee eee ee 
| Local Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ +++ 
| Local Identifier (continued) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 


NEA Sub TLV: 
The Source NE Address is an address of the transport network 
element controlled by the source network. Its length can be 4, 6, 
16, or 20 bytes long. The NEA Sub TLV is TLV Type 1. 


Local Identifier: 
A 64-bit identifier that remains constant over the life of the 
call. 


The format of the globally unique (GU) Call ID TLV: 
0 1 2 3 


0123456789012345 6789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|U|F|GU Call ID (0x0832) | Length 
t—+t—+—-4+-+-4+-4+-+-4+-4t-4-4+-4t ttt tata t tata t tata titi tata OOOHO 
| Reserved | Is | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
: 
EE AORE a AA EE EE A AE aca at 
| NE Address (NEA Sub TLV) | 


EOE E E E E E A E EE E EEE 
| Local Identifier | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +++ 
| Local Identifier (continued) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +++ 
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International Segment (IS): 
To be coded according to ITU-T recommendation T.50. The 
International Segment (IS) field provides a 3 character ISO 3166 
Geographic/Political Country Code. The country code is based on 
the three-character uppercase alphabetic ISO 3166 Country Code 
(e.g., USA, FRA). 


National Segment (NS): 
The National Segment (NS) field consists of two sub-fields: 


- the first subfield contains the ITU Carrier Code 
- the second subfield contains a Unique Access Point Code. 


The ITU Carrier Code is a code assigned to a network 
operator/service provider, maintained by the ITU-T 
Telecommunication Service Bureauin association with Recommendation 
M.1400. This code consists of 1-6 left-justified alphabetic, or 
leading alphabetic followed by numeric, characters (bytes). If 
the code is less than 6 characters (bytes), it is padded with a 
trailing NULL to fill the subfield. 


The Unique Access Point Code is a matter for the organization to 
which the country code and ITU carrier code have been assigned, 
provided that uniqueness is guaranteed. This code consists of 1-6 
characters (bytes), trailing NULL, completing the 12-character 
National Segment. If the code is less than 6 characters, it is 
padded by a trailing NULL to fill the subfield. 


Format of the National Segment 


0 I 2 3 
01234567890123456789012345678<901 
tot-t—t-t-t-4t-4t-4t-F-4F-4-4-4-4-4-4-4-4-4- 4-44-44 -t-totatatatatat 
| ITU carrier code | 
tot—t—t-t-t-4t-4t-4F-4F-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-4-t-t-t-t-t-tat 

| ITU carrie dode (cont) | Unique access point code 
tot—t—t-4t-4t-4t-4+-4F-4F-4F-4F-4-4-4-4-4-4-4-4-4-4-4-4-4-t-t-t-tat-t-t-t 
| Unique access point code (continued) 
tot—t—t-4t-t-4t-4t-4F-4F-4F-4-4-4-4-4-4-4-4-4+-4-4-4 4-4-4 -t-tatatatatat 


4.1.1 Call ID Procedure 
The following processing rules are applicable to the CALL ID TLV: 


- For initial calls, the calling/originating party call controller 
must set the CALL ID values to all-zeros. 
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- For a new call request, the source networks call controller (SNCC) 
sets the appropriate type and value for the CALL ID. 

- For an existing call (in case Call ID is non zero) the SNCC 
verifies existence of the call. 

- Intermediate nodes are not allowed to alter the Call ID TLV set by 
the ingress node. 

- The destination user/client receiving the request uses the CALL ID 
values as a reference to the requested call between the source 
user and itself. Subsequent actions related to the call uses the 
CALL ID as the reference identifier. 


4.2 Call Capability TLV 
The format of the Call Capability TLV is: 
0 1 2 3 


O12 34 25: 6: FF E 90:23. A 5 6 PBN DOL 2-3 SAS: 6 A BO OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++++ 
|U|F| Call Capabaility(0x0833) | Length 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++++ 
| Call Capability | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+++ 


The Call Capability TLV contains a 4 byte Call Capability field. The 
Call Capability Field is used to explicitly indicate the 
configuration potentiality of the call. 


An example of values of the Call Capability field is: 
0x0000 Point to Point call 
4.3 Crankback TLV 


Crankback requires that when the Label Request message is blocked at 
a particular node due to unavailable resources, the node will inform 
the initiator of the Label Request message of the location of the 
blockage. The initiator can then re-compute new explicit routes that 
avoid the area where resource shortage is detected. A new Label 
Request message is sent that includes the new route. 


The support of crankback in CR-LDP is facilitated by the introduction 
of a Crankback TLV. An LDP Notification message is used to inform 
the Label Request message initiator of the blocking condition. The 
Notification message includes the Crankback TLV that indicates the 


location of resource shortage. The location of the resource shortage 
is identified using the ER-HOP TLV. The encoding of the Crankback 
TLV is: 
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(O D2? B48 ei Be 910128) 45. 68 OF 0) D2 Bide Sr 6 8 OOo 1 
+-4+-4-4+-4+-4-4-4-4-4+-4+-4+-4-4-4-4+-4+-4+-4+-4+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4-4-4 


|U|F| Crankback (0x0834) | 


Length 


4-4-4-4-4-4-4-4-4-4-4-4+-4-4+-4+-4+-4+-4-4+-4+-4+-4+-4+-4+-4+-4-4+-4-4-4-4-4-4 


ER-HOP TLV 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The ER-HOP TLV is specified in rfc3212 [3], and consists of ann x 4 
bytes field, it could e.g. contain an IPv4 or an IPv6 address. 


5. Additional Error Codes 


G.7713 includes a number of error codes that are currently not 


defined in earlier CR-LDP related RFCs. 


conditions is given below: 


Invalid SNP ID (0x04000009) 
Calling Party busy (0x0400000a) 
Unavailable SNP ID (0x0400000b) 
Invalid SNPP ID (0x0400000c) 
Unavailable SNPP ID (0x0400000d) 


Failed to create SNC (0x0400000e) 


The list of those error 


Failed to establish LC (0x040000f) 


Invalid Source End-User Name (0x04000010) 
Invalid Destination End-User Name (0x04000011) 


Invalid CoS (0x04000012) 
Unavailable CoS (0x04000013) 
Invalid GoS (0x04000014) 
Unavailable GoS (0x04000015) 
Failed Security Check (0x04000016) 
TimeOut (0x04000017) 

Invalid Call Name (0x04000018) 
Failed to Release SNC (0x04000019) 
Failed to Free LC (0x0400001a) 


Acronyms used in above error codes: 


SNP 
SNPP 
SNC 
LC 
Cos 
Gos 
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Sub-network Point 
Sub-network Point Pool 
Sub-network Connection 
Link Connection 

Class of Service 

Grade of Service 


Informational 


[Page 10] 


RFC 3475 CR-LDP Extensions for ASON March 2003 


6. IANA Consideration 


This document uses the LDP RFC 3036 [4] name spaces; see 
http://www.iana.org/assignments/ldp-namespaces. 


Call Setup (0x0500) 
Call Release (0x0501) 


The assignment for the following TLVs: 


Op-Sp Call ID TLV (0x0831) 
GU Call ID TLV (0x0832) 

Call Capability TLV (0x0833) 
Crankback TLV (0x0834) 


The assignment for the new error codes as listed in section 5 of this 
document. 


9. Security Considerations 


This document does not introduce any new security concerns other than 
those defined in RFC 3036 and RFC 3212. 


Security aspects (if any) w.r.t. the G.8080 and G.7713 documents need 
to be addressed in those documents. 
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13. Full Copyright Statement 
Copyright (C) The Internet Society (2003). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
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